A guest started with Populated on Demand enabled (PoD) can attempt to reclaim pages which aren't regular guest RAM. This can cause corruption of memory management state in Xen.

Parts of the DMOP handling code assumes the caller has provided the required number of buffers for the given operation without any checking being done. As a result, certain operations might access stack rubble as structures are possibly uninitialized.

The EVTCHNOPexpandarray hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOPreset, resulting in dereferencing a NULL pointer.

Accesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array.

Accessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away.

Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held.

The v1 -> v2 issue is CVE-2026-62435.

The v2 -> v1 issue is CVE-2026-62436.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away.

Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held.

The v1 -> v2 issue is CVE-2026-62435.

The v2 -> v1 issue is CVE-2026-62436.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking.

The sysctl issue is CVE-2026-62426.

The platform-op issue is CVE-2026-62427.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking.

The sysctl issue is CVE-2026-62426.

The platform-op issue is CVE-2026-62427.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver derives several lengths directly from attacker-controlled on-disk fields without validating them:

The directory loop itself assumes a good record length. This is CVE-2026-42494.

The calculation of the System Use area may underflow. This is CVE-2026-42495.

The Rock Ridge extension loop assumes a good (inner) record length. This is CVE-2026-62423.

The Rock Ridge NM record processing assumes a good entry length. This is CVE-2026-62424.

The Rock Ridge CE record processing assumes a good size and offset. This is CVE-2026-62425.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver derives several lengths directly from attacker-controlled on-disk fields without validating them:

The directory loop itself assumes a good record length. This is CVE-2026-42494.

The calculation of the System Use area may underflow. This is CVE-2026-42495.

The Rock Ridge extension loop assumes a good (inner) record length. This is CVE-2026-62423.

The Rock Ridge NM record processing assumes a good entry length. This is CVE-2026-62424.

The Rock Ridge CE record processing assumes a good size and offset. This is CVE-2026-62425.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver derives several lengths directly from attacker-controlled on-disk fields without validating them:

The directory loop itself assumes a good record length. This is CVE-2026-42494.

The calculation of the System Use area may underflow. This is CVE-2026-42495.

The Rock Ridge extension loop assumes a good (inner) record length. This is CVE-2026-62423.

The Rock Ridge NM record processing assumes a good entry length. This is CVE-2026-62424.

The Rock Ridge CE record processing assumes a good size and offset. This is CVE-2026-62425.

Xenstore, to have an up-to-date picture of the entire system, wants to know of domains appearing and disappearing. To make this more robust, a new XENDOMCTLgetdomainstate was introduced. The management of the bitmap underlying that operation is tied into the binding of the VIRQDOMEXC virtual IRQ. Unfortunately an error path there would tear down the bitmap even in cases when it wasn't set up. Unprivileged domains can trigger that error path.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory XSA-508 version 2

pygrub is only supported in de-privileged mode

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

XSA-443 and XSA-497 addressed specific issues in specific file system drivers (libfsimage) used by pygrub. Further issues were reported, and yet more are to be expected. XSA-443 introduced a means to run pygrub de-privileged. Only this mode of operation is security supported from now on.

IMPACT ======

A guest using pygrub can escalate its privilege to that of the domain construction tools (i.e., normally, to control of the host).

VULNERABLE SYSTEMS ==================

All Xen versions from at least 3.2 onwards are affected. Older versions have not been inspected.

MITIGATION ==========

XSA-443 added a mechanism to run pygrub de-privileged. Using this mode will mitigate the vulnerability.

Ensuring that guests do not use the pygrub bootloader will avoid this vulnerability.

For cases where the PV guest is known to be 64bit, and uses grub2 as a bootloader, pvgrub is a suitable alternative to pygrub.

Running only HVM or PVH guests will avoid the vulnerability.

RESOLUTION ==========

Applying the attached patch documents this issue. Patches for XSA-443 added additional functionality to pygrub and libxl in order to run pygrub in a restricted environment using a specific UID. Check xl.cfg man page for information on the bootloaderrestrict option.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa508.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa508 f1e4b6490228b7fac61fd968229f98a3dfb782d56c6729d3fe01bc34c77fbd5c xsa508.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomsAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZLhoH/38QGcVs3Xc3KuskdvBx57IV/vW9XjNlVYSngmdm lKzXTZhjrecrPZvwBbhuqOBXkaFQSL17+lLVK3xRAzv2dd5hn2PqXkMj06JSwcrh haXN/JWUDwQtmJuLfGNkQ9P1W27oMXZ3pBGhv1SsEfD0mNiyC7ZZKizU291usZbF 6JMUGNUmQ1Dyom2CiylmJGmrNrHzKdfNqURc+DoSOctpS9vbT0U0xLtKYvbVr3cj 7DuITo1/gS/3pxiUw/7E5uR7zPusBGISP1ir5rBqTkgoMf2tJkt7tfygqJtrqnkU BaUt0ZCo7NBKg71o0AESZIdO3Ddg2QD6xrymtI0BVqa0n1E= =9mkq -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62434 / XSA-507 version 2

PoD: Don't try to reclaim special pages

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

A guest started with Populated on Demand enabled (PoD) can attempt to reclaim pages which aren't regular guest RAM. This can cause corruption of memory management state in Xen.

IMPACT ======

A buggy or malicious guest can cause corruption of Xen's state, leading to crashes or other malfunctions. Information leak and privilege escalation cannot be ruled out.

VULNERABLE SYSTEMS ==================

All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are not vulnerable.

Only x86 systems are vulnerable.

Only x86 HVM and PVH guests started in populate-on-demand mode are believed to be able to leverage the vulnerability. Populate-on-demand mode is activated when the guest's xl configuration file specifies a "maxmem" value which is larger than the "memory" value.

MITIGATION ==========

Running only PV guests or HVM/PVH guests without PoD will avoid the vulnerability.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa507.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa507 41485ddf0912cfa53fa05e236aa27c3c6490919ac2dab5b9f57ed69f5b38f60a xsa507.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomr4MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ+04H/i3UMWbGcPG2kp978waMmF3Gtfb/r8mw3UBzVGCi cIOBWf/FizjWu54SQEQtjwYPfi0nKftFN1UPqAGs+OUtyiZ8EcPL5x9i7arrqA2T uGfpCTb3NtFmacBbrpGnqkNahMtSLWtE8aSVEQhLxvZcLTPB6OPzIi/MVPGyA7jl /LSGWs4vd99Y8ZvAN20rhxaEAjYynfd7N4tXn38EoW9WiQBuPZ5eNzsbieah8PEo Ajntyx774ipvtYYStA4fhsLwO+6LyqH7okDR1g8Xkq6IVrOshP194mxnsuEfcMIO 4TCkWbzhmspfxQ1E2aW2VVPzIC2X2b+i8JieUK/z3mmrRSU= =AfG5 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62433 / XSA-506 version 2

correct buffer checks for DMOP hypercalls

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

Parts of the DMOP handling code assumes the caller has provided the required number of buffers for the given operation without any checking being done. As a result, certain operations might access stack rubble as structures are possibly uninitialized.

IMPACT ======

A device model of a HVM guest can gain insight on the contents of the Xen stack, thus possibly leaking data from other guests contexts.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.10 onwards are vulnerable. Xen versions 4.9 and earlier are not vulnerable.

Only entities controlling HVM guests can leverage the vulnerability. These are device models running in either a stub domain or de-privileged in Dom0.

MITIGATION ==========

Running only PV or PVH guests will avoid the vulnerability.

(Switching from a device model stub domain or a de-privileged device model to a fully privileged Dom0 device model does NOT mitigate this vulnerability. Rather, it simply recategorises the vulnerability to hostile management code, regarding it "as designed"; thus it merely reclassifies these issues as "not a bug". The security of a Xen system using stub domains is still better than with a qemu-dm running as a Dom0 process. Users and vendors of stub qemu dm systems should not change their configuration to use a Dom0 QEMU process.)

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa506.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa506 7fa79f0421eafa420f7af791ad35a96a769c945260d81419052611771347b411 xsa506.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZNF4H/0c6JMsivAWWDIQ920Bwh7EEOKhMv3nGIrBqrN8/ TGKJNNoNQinhoQv9fnqwsHaiC8e49PNUJqTpEN8/o/b0obnl4Tw2JyUXFY1bZyaz XNS85rkrUc0+Ue/Ka2464mmQ826TJXfaXG9CZYlC5cO/JtzX65ecMW4H7ju2tdnt c9xK+I5kIQPwUwy3HUMrKFvWi+JIvpCzhuHYDH2iJDecmk42pOmnKtS54q6YO15n c4xdn7aNyeECKQw4qUcjKC7zKRgrqFu5J3BlvXauZOkJCL50PK+OpWK6QV+fRNGy N7dnY5w+1BMVrHywZI5iy8WqZtJoi6TOO1Gl0WcB07/vvJk= =APkr -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62432 / XSA-505 version 2

evtchn: Race between FIFO expand and reset

UPDATES IN VERSION 2 ====================

Typo correction in description.

Public release.

ISSUE DESCRIPTION =================

The EVTCHNOPexpandarray hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOPreset, resulting in dereferencing a NULL pointer.

IMPACT ======

A malicious HVM guest (x86 HVM or PVH, and ARM) can crash Xen leading to a denial of service.

A malicious x86 PV guest can most likely crash Xen leading to a denial of service, but memory corruption or privilege escalation cannot be ruled out.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.

MITIGATION ==========

There are no mitigations.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa505.patch xen-unstable - Xen 4.17

$ sha256sum xsa505 80619fdbb547dea191439ef1c9539fa0991e8f6c449b3970a086f3287fb9ce6e xsa505.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ5H8IAMKtDfTsBJaoOosFHEU0Gyv96fP98D89URo21RrD V+Lpd9CTatYuTnz53gztlUa7s2/ARYl488bNURwPTdTjSEdJBbFQKrEyAZsryTyh hiIJF7AhQf8LsY3qk2xuJ+/tKc720WK/zsUGVRz6Jhf9W90g5wBhIM1RAhfy7H2t Zn74wXDi4dsMLQg6VivzRq+y+XJfZKR6qoKztiDHk0DBobmJzQFF2cfkiiWDRW9l NuvLxKjsPyS4K+Jcm9k65RzmWfDprxmL/63VDAt0W8dSAe+u1zyDh/aT+OFK5R1g c6CwdjquY4hhSYhwix4TW18LRlY0NA/pqn3FmhLQl3XZmfU= =z4Qy -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62431 / XSA-504 version 2

Viridian STIMER division by zero

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

The logic to handle periodic Viridian STIMERs performs a division with an unchecked user-controlled divisor value, that can be set to zero to cause a #DE fault.

IMPACT ======

Enabling Viridian STIMERs to unprivileged HVM guests can result in a Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.13 onwards are vulnerable. Xen versions 4.12 and earlier are not vulnerable.

Only HVM guests with Viridian STIMERs enabled can trigger the vulnerability.

MITIGATION ==========

Not enabling Viridian STIMERs for HVM guests will avoid the vulnerability.

Note Viridian extensions are not enabled by default.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa504.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa504 cc142e53866a27f3c97bd8532f42df2197f9e8e85fb3846b6fcd682d854e5689 xsa504.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomroMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZiF4H+QFl08pzXWh5Zd2uOlbjYCaQMoDFeWSGCAkCcG8z PlKv4yVLPwxUB0W5cPVV61M/fFDgihZh0usNZ/xm5aTt0uhPE31kXItsYRRLPpmg zbV5OgUgIJxeAABML030lNjlAyLBpVculHAWbyFZdMh/xf0bQc1ty8U/xQDLU+IE cohmtH8v6WvK2PxTA8nNj39EB9rUcz1gYInLh2QltW14di7+FUHGISxiIr/eNcUv 9d/at8ESSH1WNeSRSr+sbE0dMRxAQgoMa93GvU7sEvuZtdwOnnET8l1nVN/84kXM sCMq6mjgVDUmSNOH2aBXxewimjp9DV0BLkmliqHrHDKer3s= =intH -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62429 / XSA-502 version 3

vNUMA domain cleanup may race other operations

UPDATES IN VERSION 3 ====================

Public release.

ISSUE DESCRIPTION =================

Accessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest.

IMPACT ======

While Denial of Service (DoS) affecting the entire host and information leaks and are the prevailing effect, a device model stub domain or a de-privileged device model running in the control domain may also be able to elevate its privileges to that of the host.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable.

Only entities controlling guests (on x86: HVM guests) can leverage the vulnerability. These are device models running in either a stub domain or de-privileged in Dom0.

Only guests which have vNUMA enabled allow their controlling entities to leverage the vulnerability.

MITIGATION ==========

On x86, running only PV or PVH guests will avoid the vulnerability.

Not enabling vNUMA for HVM guests will also avoid the vulnerability.

CREDITS =======

This issue was discovered by Teddy Astie of Vates.

RESOLUTION ==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa502.patch xen-unstable - Xen 4.22.0 xsa502-4.21.patch Xen 4.21.x - Xen 4.19.x xsa502-4.18.patch Xen 4.18.x - Xen 4.17.x

$ sha256sum xsa502 e6150a6c468906a1bbcd4b9fca1f28cf3dc2c4617d6aab7c48507dbac003df82 xsa502.patch f780c280539aedb3eeb4f5a43f3d2f4bc5a112ca1a2d7ad6a95eb2fbdc5f5cc8 xsa502-4.18.patch a0b2b6f543a566e997a9f38bbd718cc81e8de8e7b442ff47e92260f70e66f647 xsa502-4.21.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted.

This is because no longer exposing vNUMA is a guest visible configuration change, which may lead to re-discovery of the issue.

Deployment of this mitigation is permitted only AFTER the embargo ends.

AND: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrQMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ58sH/2CogHDnmyLVcaB68ySxCnCZI5qNt0VonyH4n3s0 Ef4H74nwh3osLXrvkcnXvbrH4hqDKI3MtydScfHc5dpa1rQHXO8utHxZtGUU+CSv A1nSYD42pu96V5xvTXO+xK5sCZoBREgUNS2TGCE02dkwXdngsCWnAPFn1BQi7wsG LJWuzurlSRSc28PPuIEaKJM+eiyG88ep5fADrLycVPvltqd6bktEE1Xa82h5iSYd 9K7KTEDT9Kc0HZEg4x0h2OBwVqGdKF+8FHDNCEtpiwtE2Ao6OycTVzGNX7f+fq4/ CeQjI8I94j/r1zVPtuGBHNVkUdgrCIe36156RC7f1LFy0JM= =7hf1 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62435,CVE-2026-62436 / XSA-501 version 4

grant-table: version change racing with other operations

UPDATES IN VERSION 4 ====================

Properly sync backports with staging patch (there was no functional issue, just a code arrangement one).

Public release.

ISSUE DESCRIPTION =================

With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away.

Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held.

The v1 -> v2 issue is CVE-2026-62435.

The v2 -> v1 issue is CVE-2026-62436.

IMPACT ======

An unprivileged guest may be able to elevate its privileges to that of the host. Information leaks and Denial of Service (DoS) are possible as well.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.0 onwards are vulnerable. Xen versions 3.4 and earlier are not vulnerable.

Only x86 guests permitted to use grant table version 2 interfaces can leverage this vulnerability. On Arm, grant table v2 use is explicitly unsupported.

Only multi-vCPU guests can leverage this vulnerability.

Xen versions 4.13 and newer offer a way to build Xen without grant table support. Such hypervisors (CONFIGGRANTTABLE turned off) are not vulnerable.

MITIGATION ==========

Using the "gnttab=max-ver:1" hypervisor command line option will avoid the vulnerability.

Using the "maxgrantversion=1" guest configuration option for guests will also avoid the vulnerability.

CREDITS =======

This issue was discovered by Mark Esler.

RESOLUTION ==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa501.patch xen-unstable - Xen 4.19.x xsa501-4.18.patch Xen 4.18.x xsa501-4.17.patch Xen 4.17.x

$ sha256sum xsa501 e856d64f5b1a16dbb3d7ec19140f24eca508b62de0d25036fa5735cdd5b72be6 xsa501.patch e006c4fe0a35698318eca59ce828202cac19327f5139d51645116124fc3126e8 xsa501-4.17.patch 10477adfd82fa09123f08497d6a5d44ae61f48d026590ce262cac65f482b2d97 xsa501-4.18.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public- facing systems with untrusted guest users and administrators.

HOWEVER, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted.

This is because restricting the available grant table version is a guest visible configuration change, which may lead to re-discovery of the issue.

Deployment of this mitigation is permitted only AFTER the embargo ends.

AND: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrIMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZc98H/0wOjr4aa/IMxNH41B8p6vx1ayiBDvTV8qWgmjf9 AyjNGWG5sAjViMDjtFMUE/CeOeoby+gPRfzop9L7cjlHzy8+y/5s9oRUzC+0VIDq 1V5SBbD0XzhqujoLj5LBF0M1a/EyAJzYeVIV3t1DL6yFAz9YRpUGz6pNAwnF0dui bfNZcT2K0+BV0YHUQMrEkAUd+PV/mObG8AiVDS8j9BU8sGN4m1Wx2hsYzqYBCXpK T3lT8dG9qaYcnlH+m9jfWFIE2Srr9a2rLdCMs4dHY1CB/FmZLRrWe304yFuQntET OGiyZWW86cjmANEKAjrYHSD/CRa81gBqdxiAH/N13zBxZ7I= =VVHS -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62428 / XSA-500 version 2

grant-table: type confusion in grant-copy

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

When grant-copy operations are processed, the respective grant may or may not already be in use by another operation (a mapping or another copy). For all copy operations the referenced guest frame is looked up. When another operation is already active for the grant (the grant is "pinned"), what is being supplied back to actually carry out permission checks and copy operation may not be consistent: The permission check may be carried out on a page different from the one involved in the copy.

IMPACT ======

An unprivileged guest may be able to elevate its privileges to that of the host. Information leaks and Denial of Service (DoS) are possible as well.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.2 onwards are vulnerable. Xen versions 4.1 and earlier are not vulnerable.

Xen versions 4.13 and newer offer a way to build Xen without grant table support. Such hypervisors (CONFIGGRANTTABLE turned off) are not vulnerable.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered by Roman S.

RESOLUTION ==========

Applying the appropriate attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa500.patch xen-unstable - Xen 4.18.x xsa500-4.17.patch Xen 4.17.x

$ sha256sum xsa500 e09e06ef5d4044b4c6104ae83d5e509d45495d7bab1da73f2beb7a916d24f462 xsa500.patch 5fabb02fd4cc62f58a07a8322883b04c638832f65fdf0216a0efde6229d1fd73 xsa500-4.17.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomrEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ4B4H/1dGUPMt2yREv0C6uHyxT50MoAwaZ01A6Dwm2CNm 2eIjsJGeF3mtlw0T4c6hCmF7fcULFJMcPkJi09TS38ADIOBpivgP+tRkRa+ZRPtG E6vpRtlHmD57WVPWRfTM0uk6UL/CCyvlUILR8A9lu7tF5PFef3Dzeiqpuh/rMNPx DmEcn3Mw8DpKvkoMIVJd1TgAtFX0KwWwByxClUIV84K2SBvcNxVoiw2fkKkx1HRa lB7sVEkKliUyIN/uWmh1VcLshQuulHYNcnkq7ErCEIQqo30ay6WER6W5TS0cfh/F OUSQWlWzkht2GY0pRXp5UQaBFc8UCsOnVty8DhvLrCyllSk= =gRtn -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-62426,CVE-2026-62427 / XSA-499 version 2

sysctl and platform-op locks open to abuse

UPDATES IN VERSION 2 ====================

Add further tags to patches.

Public release.

ISSUE DESCRIPTION =================

To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking.

The sysctl issue is CVE-2026-62426.

The platform-op issue is CVE-2026-62427.

IMPACT ======

A less privileged entity may stall an equally or more privileged entity, potentially leading to a Denial od Service (DoS) of up to the entire host.

VULNERABLE SYSTEMS ==================

All Xen versions from 4.0 onwards are vulnerable. Earlier versions use a different locking operation, but may also be vulnerable.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION ==========

Applying the appropriate set of attached patches resolves this issue.

NOTE: The patches include an adjustment to the default Flask policy. When custom policies are in use, a respective change will need making there.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa499/xsa499-?.patch xen-unstable - Xen 4.21.x xsa499/xsa499-4.20-?.patch Xen 4.20.x - Xen 4.19.x xsa499/xsa499-4.18-?.patch Xen 4.18.x xsa499/xsa499-4.17-?.patch Xen 4.17.x

$ sha256sum xsa499/ 1b716186d37cb6be7b2917bc4801a5d431111f6a01f6e710e2899b6fbf91d747 xsa499/xsa499-1.patch 7789699993f993aa0f118437b9a18c2207cf29491fa08f21e029aa4293698d38 xsa499/xsa499-2.patch 4860a286a7161a407a7e7dc95ecb04a453847295ca73f91f3bd07c3e9e94b7fe xsa499/xsa499-3.patch fd59436b871caad09017da250996968797ada23223b1e76f9a2e80ae814d63ca xsa499/xsa499-4.17-1.patch 9f83e4866fd20a3e45ecf40a80898446d243444fdf4c17eb695ff7f3d3e9f816 xsa499/xsa499-4.17-2.patch e7e4fcb7502deb605a854ce451403237ea295394dc30f771001680cc3aaa8f9e xsa499/xsa499-4.17-3.patch 3a979d5c59d690313ec9c3d82d8859dadd6d106296cbf6fe75ef9b42f2626bb5 xsa499/xsa499-4.17-4.patch d2b3bcad9eb0d82f16befff35ef8fa0d8ed6d06b7e7e2c360003f1eee14d26b2 xsa499/xsa499-4.17-5.patch ac1f4d1935dc7546c32e5b9c42ebd08d71ca232e559a7021e3ed685c0973675e xsa499/xsa499-4.17-6.patch 143a9b46b3edf689e8b75fb87d1e15b0f0b96baf48547f6d77c00ba5e90ea5ac xsa499/xsa499-4.17-7.patch cd51ddc70ac765ef00a404d3a21c04a0e234ebca1904159820504e10f70e3812 xsa499/xsa499-4.18-1.patch 32f7827da6a6cdff848a1b620dd1a4d4861008f53d31050c6cde1d353794d22f xsa499/xsa499-4.18-2.patch 3ed288dd99051ebb014cf1cd124d5ed0837935bb0d56963f54699a9e3a966c4e xsa499/xsa499-4.18-3.patch 86fecda24801913f408f86db0b02d0017e870fa95e6edfe5d414343c89b29b37 xsa499/xsa499-4.18-4.patch 055c9114e0c1e789ee510dfb739bf8067a7acbdad6b6edaf2c0e7ed3daac2b81 xsa499/xsa499-4.18-5.patch 211b7410562f438e82266d3101beaef32d66c54b4681a370dd3e47abeec7c5c5 xsa499/xsa499-4.18-6.patch a0849d860536a199ebeabb6199012d9eae70ee2ed41573765af50aec7b7e7f85 xsa499/xsa499-4.18-7.patch 48b96df5981193f182eda567ad65f1343718656a36ea1ef2d24bdc534ea4ead1 xsa499/xsa499-4.20-1.patch 3e9a315184f64d41011721b2f09275fcc6969d46be3c6f6b788b65fe78c1a0a8 xsa499/xsa499-4.20-2.patch cf66937eecf0b8a559e60553c21de0e3767270df022c7098d7dd94a46c5ad176 xsa499/xsa499-4.20-3.patch 8932a1480b7431a0ebb048312dda49d5b7d06a5d2b57efb04df0b90bc81e95be xsa499/xsa499-4.20-4.patch 6777a824bc0248f8e12a71f87b60a3209a7a74a08fe7e072d26f80095d188a01 xsa499/xsa499-4.20-5.patch 3ab8c66b133d2b942f7caad0251d427076ad2ef38bcbf6672a937c1406f098ac xsa499/xsa499-4.20-6.patch 1254cc886eb62d65624bcc417701c119e02cc35d31f62e3dda1bda062e170446 xsa499/xsa499-4.20-7.patch 70c315beca0afa411c9e31117d8e0b22b36b5cd70e8d9d2243f5501167a2c631 xsa499/xsa499-4.patch d0ff37c4807445bd5146057ddaed31d7ce5a0fe6abf413a04f4bceca8419baeb xsa499/xsa499-5.patch 961d31a715ae2c8dd25b74243a6c759ce8c43409c4156ae6bbdcf3faac03f592 xsa499/xsa499-6.patch 60cb3b1e4beef97d633a0156feb0f4f10ac8d21c54152969f5b7a77ecc4a24d3 xsa499/xsa499-7.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomq8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ9AcH/3XOTFbTvmwW48Q6nVkwvys5fiU2esrkFOTK96nn p55QQoVVjebet7N+eRtezkjfHGCqphGOuHcAJ0uMlNNgUfhXNxxu6qaqMHX5h29P DqQKZzOKuQM1frcyupJdhi8dbNxan1pXMv6rJAcWpmBoPEt9e+qwpnWtBX/HPH3b 66cQwLhmenlqwZak7E0bsLFw1A6WUXs1VS4xeiOE3Cj91F5hPUvqkZGI0pNbNAIn 6copsM0UAcTkwGrwIvKuN5b3BqFmaCWvGBfqsuNpj5MnJddigV68UeylMepFjoDH Urn2qiOTcJKxdFt/AUX57AqiBF2MtDbi49RLLxsTCJvYvFM= =R0It -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-42494,CVE-2026-42495,CVE-2026-62423,CVE-2026-62424,CVE-2026-62425 / XSA-497 version 2

buffer overruns in libfsimage iso9660 handling

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

The directory and Rock Ridge / SUSP walk in libfsimage's iso9660 driver derives several lengths directly from attacker-controlled on-disk fields without validating them:

The directory loop itself assumes a good record length. This is CVE-2026-42494.

The calculation of the System Use area may underflow. This is CVE-2026-42495.

The Rock Ridge extension loop assumes a good (inner) record length. This is CVE-2026-62423.

The Rock Ridge NM record processing assumes a good entry length. This is CVE-2026-62424.

The Rock Ridge CE record processing assumes a good size and offset. This is CVE-2026-62425.

IMPACT ======

A guest using pygrub can escalate its privilege to that of the domain construction tools (i.e., normally, to control of the host).

If the mechanism introduced by XSA-443 (see the mitigation section below) is in use, then the guest can only escalate to this limited context.

VULNERABLE SYSTEMS ==================

All Xen versions from at least 3.2 onwards are affected. Older versions have not been inspected.

MITIGATION ==========

XSA-443 added a mechanism to run pygrub de-privileged. Using this mode will mitigate the vulnerability.

Ensuring that guests do not use the pygrub bootloader will avoid this vulnerability.

For cases where the PV guest is known to be 64bit, and uses grub2 as a bootloader, pvgrub is a suitable alternative to pygrub.

Running only HVM or PVH guests will avoid the vulnerability.

CREDITS =======

This issue was discovered by Syed Abdul Khaliq of BugQore.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa497.patch xen-unstable - Xen 4.17.x

$ sha256sum xsa497 65925ac5a322b9eacc8538d6486e3e37ddcb83fe6f02f61c18216ccd2770f964 xsa497.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomq0MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZyesH/0dz6MuK3DsILiWvYuGNuX//RcdpBlQtLmyQR382 vpoicCuEAJLJlZFZsPddIxjTxte77nbFs2Ih51br95J//ou6sX7q6V9wDGt4EHDK pF4ECI8SCkHDszogIDGDFiSdi7V7VknGpLCjFtINaAcaRLMHx+MMcdMV80IZyoXw 8p2XY7xvaXyo90I1FiecN7yU0H49sYJswLvihJU55hDuBZ25HLe2K59UGs2uaVm2 J0QKIBi3k20kZ5p9diny+cjU81fVu8LwGPKjvK3KUoyNnFsNbsO5owrAq2w/FSbE 1K54Lj6FXk0w08c4S0kz4zLXKLhSeCl7hFvqUpmQAXaN7ew= =0lw8 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-42492 / XSA-496 version 2

vIRQ event channel binding may break Xenstore

UPDATES IN VERSION 2 ====================

Public release.

ISSUE DESCRIPTION =================

Xenstore, to have an up-to-date picture of the entire system, wants to know of domains appearing and disappearing. To make this more robust, a new XENDOMCTLgetdomainstate was introduced. The management of the bitmap underlying that operation is tied into the binding of the VIRQDOMEXC virtual IRQ. Unfortunately an error path there would tear down the bitmap even in cases when it wasn't set up. Unprivileged domains can trigger that error path.

IMPACT ======

An unprivileged domain can affect the operation of Xenstore, potentially leading to a Denial of Service (DoS) affecting the entire host. A hypervisor crash with similar host wide effect also is possible, albeit unlikely.

VULNERABLE SYSTEMS ==================

Xen 4.21 and onwards are vulnerable. Xen 4.20 and older are not vulnerable.

MITIGATION ==========

There is no known mitigation.

CREDITS =======

This issue was discovered by Grygorii Strashko of EPAM.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa496.patch xen-unstable - Xen 4.21.x

$ sha256sum xsa496 80a0a807dd9d7ae793b462d78da2bd9d4f84eb5062f3e60622d12edde9c2a27c xsa496.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomqwMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZc8IIALEzvp6RymbSYDSTBqNl4k+mRBOfMTdwOGKA9lNm zYl9rFlGcTTR2HogU9Vplm0gQmcrksFndwXMzjkOqLlRnbDs6JsSIpuQaWi6jm7f Fj0QLAMXLxLLMAPvC8j9kLJjJrlv7X1VeYolsHBSq3lCoqb5YgZaqMIDuOXgO9+7 //cSTRbaEnm4UBrV/WxUX1pd6RHOBbioJjyLwy4QZyfoTfXtVrw6bv5IHsq8GyD6 QYRFnh9fZ+33p7LDoU5jUlDO+TnJZeUlbWGqMTsxdGx8l93662nNGDIYrxJr+/8g 6CmXyObBkiI3qXRT7sSt1/FzdnoDIQTPtIyv4xuIi4GMT+0= =V0J6 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-42493 / XSA-495 version 2

x86 shadow paging is deprecated

UPDATES IN VERSION 2 ====================

Updated the patch for staging with further CI adjustements.

Public release.

ISSUE DESCRIPTION =================

Addressing certain issues, in particular related to operations which may take excessively long and therefore would need preemption, has turned out overly costly. Since alternatives (HVM/PVH: HAP, PV: shim) are commonly available, the decision was to deprecate the functionality, while still retaining it for people to use at their own (security) risk. Memory-wise small enough guests may still be okay to run.

IMPACT ======

An unprivileged guest may be able to cause Denial of Service (DoS) affecting the entire host.

VULNERABLE SYSTEMS ==================

All x86 systems with builds of Xen having SHADOWPAGING=y are affected. Note that prior to Xen 4.7 this control didn't exist, and all builds of Xen would be affected. (Strictly speaking Xen 4.6 had a different, harder to use mechanism to disable shadow paging support: One could pass "shadow-paging=n" on the make command line.)

MITIGATION ==========

Running HVM and PVH in Hardware Assisted Paging (HAP) mode will avoid this vulnerability.

There's no mitigation available for PV guests. This is because shadow mode, if support is enabled in the hypervisor, could be engaged at any time. Note that without shadow mode built into Xen, guests not properly dealing with L1TF will simply be crashed instead.

RESOLUTION ==========

Applying the appropriate attached patch documents this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa495.patch xen-unstable - Xen 4.22.0 xsa495-4.21.patch Xen 4.21.x xsa495-4.20.patch Xen 4.20.x - Xen 4.19.x xsa495-4.18.patch Xen 4.18.x xsa495-4.17.patch Xen 4.17.x

$ sha256sum xsa495 949624ce241ddc455c43cdde0ff045cc5fdf29b69f06f7079fa8f1d2400e1d9d xsa495.patch bb1fea4b49840b81a1a7ca86124e308f23edd6eb078857d44d9ebaf1b352b374 xsa495-4.17.patch 06f2c862df85a17b9dc1d4a0df42cadb97e24b7033c070c9ad74ad72d278af0e xsa495-4.18.patch bffa5816be9ddf0fabec0509f2b74e30a5dd0e5429a3b7919e304150cb5091f2 xsa495-4.20.patch 7092cf37dbcfecc9aa6bf9a2836ed70f48f52bccb9630e94c89d2afe120b47f5 xsa495-4.21.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of patches or mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted.

This is because switching HVM or PVH guests from shadow to HAP mode is a guest noticeable change, while for PV guests the lack of shadow mode is noticeable because they then cannot be migrated anymore, and guests not properly fixed for L1TF would be forcibly crashed.

Deployment is permitted only AFTER the embargo ends.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmpomqUMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZH9wH/2EYJsV5YVdJsoQSlG94dqOR7IDPEI2I17wUVSoG OK6BaqaejA1SHJbt0/wSkhJ9er+1UHzgr61S7EnE813mugu7T9nwTku1/++4DB9O V/ID/NZzWwGJ2EjCHGrVTPZvmxMmVBGZs3bex00xrQ83y97D3TfmCRH0k6ip7sUh kKSmdvTdlnODuV1+3KT09RIpDvOjVGXLpnd22++0CcT0eFoOrn0nH2dgdUw/grTf 7ye6pGcj2xViznw7FDJnXG4XOAC+wIBMX9HJK6rMOFR9P2DFUxUEcYVN+DlzR67h 3Mejc9U4Ll+65RoZbI01lmpnpqEJ33kPRGkwzA0CJmkF8wQ= =evRY -----END PGP SIGNATURE-----

Some shadow paging errors paths will switch the page-tables without updating the currently running vCPU reference. This causes a mismatch between the loaded page-tables and the mapcache metadata which can lead to corruption of the mapcache.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489.

Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.]

To create and manage guests, domctl operations are used by the control domain, a possible Xenstore domain, or by a domain controlling a particular guest. Some of these operations may not be executed in parallel, so a system-wide lock is used. The way that lock is acquired is, however, not providing any fairness. This is CVE-2026-42489.

Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. This is CVE-2026-42490.

HVM guest I/O port accesses are subject to either emulation or at least translation. Translations are managed by the device model (via XENDOMCTLioportmapping), and hence the linked list used may changed at any time. Traversal of those lists (while handling guest I/O port accesses) therefore needs synchronizing with updates, which was missing so far.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Xen Security Advisory CVE-2026-42488 / XSA-494 version 3

x86: mismatched mapcache metadata

UPDATES IN VERSION 3 ====================

Public release.

ISSUE DESCRIPTION =================

Some shadow paging errors paths will switch the page-tables without updating the currently running vCPU reference. This causes a mismatch between the loaded page-tables and the mapcache metadata which can lead to corruption of the mapcache.

IMPACT ======

Privilege escalation, Denial of Service (DoS) affecting the entire host, and information leaks.

VULNERABLE SYSTEMS ==================

Xen 4.15 and onwards are vulnerable. Any Xen version with the fix for XSA-438 applied is vulnerable.

Only x86 systems are vulnerable. Only 64-bit PV guests can leverage the vulnerability, and only when running in shadow mode. Shadow mode would be in use when migrating guests or as a workaround for XSA-273 (L1TF).

MITIGATION ==========

Running only HVM or PVH guests will avoid the vulnerability.

Running PV guests in the PV shim will also avoid the vulnerability.

CREDITS =======

This issue was discovered by Roger Pau Monné of XenServer.

RESOLUTION ==========

Applying the attached patch resolves this issue.

Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches.

xsa494.patch xen-unstable xsa494-4.21.patch Xen 4.21.x xsa494-4.20.patch Xen 4.20.x - Xen 4.19.x xsa494-4.18.patch Xen 4.18.x xsa494-4.17.patch Xen 4.17.x

$ sha256sum xsa494 6e3328f73000afdfffa5e4d9fec89a4c9456d97758bfa1a0605765a386565328 xsa494.patch 483675d6cb69b70e919110f58814b047787c3b53def344cf32f4acdd7ee9b271 xsa494-4.17.patch e637dce8cd5ecf7c30501ab2eb0af5240ff0a36844b257ca7dd14094d5118aa2 xsa494-4.18.patch a70aa60fb5dcf171025c5d90e332dcae95a83bbf9d42ab45451f629621f455e5 xsa494-4.20.patch 14f9698060c523893f710cc5ab3ec723c75a99e5caa193b9281d4a06016bf687 xsa494-4.21.patch $

DEPLOYMENT DURING EMBARGO =========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmon+5MMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZ+HcIAIpJbk3ISxjsn0ZFBXR01iOGubj+Y/vKE4mdJe1y 1//aeWPL26enDoyZ5KoT+hiC2qogTfT1p71MIS0Gns44UfVOw95xlrd0eUO//5td NQk7YFYn/WB+z9KWcdV8+Lo3zKiMNFiILCeK2+WefByfBQfZ/WFBQ48WZpxnkxHo j7cgtmtmTStmIDEWxY0pfdEWHPCBGX3SvUGWKR2tl5tZZxjd+yIij4fjLzUCKxU3 r4dYblTAg0JyDsI2SR16TLRSKyWxnwprzlb2fJEDsZXoZvIetf6jhHpvfFY+Z2m1 zlLfFDam+oGQI1CwrMNCz69AaeJzyTnRdiY+BM51lpgdjj0= =pLmw -----END PGP SIGNATURE-----